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A VIRTUAL SYSTEM CONHGURATOR SERVER FOR LINUX 

BACKGROUND OF THE INVENTION 
FIELD OF THE INVENTION 

The present mvention relates to an apparatus and a method for 
supporting computer system management, in general, and for providing assistance 
to system managers in the process of configuring, installing, compiling and 
upgrading a computer system, in particular. 

DISCUSSION OF THE RELATED ART 

Computer systems are a collection of computer programs. Modem 
computer systems aire modular in the sense tbat are designed and actualized using 
as building blocks a plurality of functionally interconnected software modules. 
The software modules that constitute the computer systems are computer 
programs as well» communicating in the standard manner of computer programs . 
by passing arguments. 

Requirements from modem computer systems are extremely 
demanding, therefore a contemporary computer system consists of a remarkably 
complex set of instructions. Apart from the conventional functions routinely 
expected from an operating system portion of the computer system such as 
memory management, file control^ I/O commands, buffering, process scheduling 
and the like, computer systems today are additionally required to function in 
complex operational settings such as a multi-user enviroxunent. The support of a 
plurality of diverse and sophisticated services such as multitasking and 
communications became a standard requirement and so did the demand to support 
a vast and steadily growing niunber of sophisticated interfacing methods to 
increasingly advanced hardware devices. As a result prevalent operating systems 
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Typically, upgrading a computer system involves either adding new 
components to the ones already in. place or replacing existing components by 
recCTtly developed or improved versions thereof. The process involves collecting 
the appropriate conlponents jBrom one or more sources (commercial software 
companies, independent developers, distribution sites on the Internet or any 
combination thereof) and installing the components by means of appropriate 
utility programs. The installation utilities could be part of the original computer 
system or could be supplied by the vendor and/or the developer. 

The specific operation of altering a software configxuation involves 
installation, uninstallation, replacing of software components or any combination 
thereof. For the purposes of a clearer description all types of software 
configuration changes will be referred to as '"upgrading" in the text of this 
document 

* 

. The majority of the available installation utilities operate in a basic 
fashion. The components of a new type to be installed are inserted and abided to 
the computer system whereas new versions of existing component types overwrite 
tiie previous versions rendering them thereby inoperative. The computer system 
configuration files are updated accordingly and the original configuration files are 
removed. Installation utilities of a more advanced type include some operational 
safety measures such as storing the deleted components in specific storage areas, 
saving original configuration files and providing a list of actions performed Some 
specialized utilities check for inter-component dependencies and provide 
warnings about possible incompatibilities between the original system 
configuration and the set of components about to be installed. In the face of these 
unfavorable circumstances the utility programs typically display a warning 
message, discontinue the upgrade process and permit the systmi manager to solve 
the problem in a conventional manner. Solving the problem in such a manner may 
require a extended time-period as it may involve the reading of a large amoimt of 
documentation before proceeding, a plurality of requests for software support 
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SUMMARY OF THE PRESENT INVENTION 

One aspect of the present invention regards a central server system on 
which a software components upgrade simulation process is based. The central 
server is having a storage device, an 1/0 ^device, a conmiunication device, and an 
operating system. The virtual system upgrade method consists of gathering 
information related to software components, researching said information, 
collecting and storing relevant component objects and associated ioformation, 
encoding the dependency relationships of the collected components into a model 
of dependency rules, storing said dependency rules, validating said dependency 

■ 

rules and making available to system managers of connectable client system to 
utilize the collected, stored and encoded information to perform a conflict-firee 
virtual system upgrade configuration and cbnsequently depending on the results a 
software system upgrade operation. . : .i: 

, A second aspect of the present invention regards a virtual systeni; 
configuratiorL system based . on a central server system for tiip iise of system 
managers of client system connected thereto. The central server system is having 
a storage device, an I/O device, a communication device, and an operating system. 
The virtual system configurator consists of a knowledge database, a component 
object database, a liser preferences table, a rules language module, a component 

t 

input module, a component validation module, a client requests and queries 
handling module and a knowledge base handler module. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

The preferred embodiments of the present invention are in the conteict 
of the Linux environment Linux is a fiiU-featured UNIX-like computer system 
that was designed to provide personal computer users a free or very low-cost 
operating system comparable to tiie traditional and usually more expensive UNIX 
systems. Linux has a reputation of a very ef&cient and fast-perfonning system. 
Linus Thorvald of the University of Helsinki in Finland has created the Linux 
kernel, the central part of the operating system. To complete the operating system, 
Linus Thorvald and other team members made use of system components 
developed by members of the Free Software Foundation for the GNU project 

Unlike traditional proprietary computer systems, Linux is publicly 
open and extensible by contributors. Because it conforms to the POSIX standard 
user and programming interfaces, developers can write programs that can be 

ported to other operating systems. Liuux is distributed commercially by a number 

■. - - . . 

of companies. 

As the source code was made freely available and further deyelopinent 
by others was widely encouraged, a massive, worldwide development is pursued 
today by a great number of companies, programmer teams and individuals 
independently or in cooperation with others. As a result of this extensive activity, 
a multipHcity of new drivers, modules, packages, and applications are written and 
distributed for Linux constantly. The new systems, versions, and components 

are all potentially installable and operative in every Linux 
installation circumscribed only by the processor type. 

Linux is a powerful and popular operating system and it is widely used 
on personal computers. It will be readily perceived that a proposed solution 
designed to support the management of computer systems will be particularly 
suitable for the Linux environment The present invention overcomes the 
disadvantages of the prior art by proposing a novel metiiod and a system, which 
provides an autoinated or a semi-automated mechanism to the purpose of altering 
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specially designed knowledge base, which is subsequently validated by repeated 
testing of the component relationships. The research and validation jprocesses are 
also continuous. Consequently at any given point in time the knowledge base 
, consist of state-of-art component objects and an up-to-date abstract model of all 
the existing interdependencies thereof. Typically, the component object files 
include the most recent component objects available and the latest versions of the 
existing component objects. 

Users of client systems operating in a Lunix environment and requiring 
a system upgrade connect intermittently to the central server-based knowledge 
base. The server system provides . a specially developed virtual system 
configurator software that enables the users to export the knowledge base from 
the server, resolve the conflicts resulting of the virtual system upgrade, download 
and iBSfll fl« con^n^ objects and perfonn a «al system 

Typically, the process is initiated by user request. ' - ^ 

It will be easily perceived by one skilled in the art that in an another 
embodiment of the invention the above-described process could be automatic or 
semi-automatic according to die user' s decision. . . r . 

Referring to Fig. 1 there is shown constructed and operative in 
accordance --with the preferred embodiment of the present invention the 
computerized environment in which Virtual System Configurator Server system 
22 is operating. Components 12,14,16,18 are retrieved, entered into server system 
22, stored on a memory device on server system 22 and processed by component 
handlers 24. Component objects 25 are stored into component object files 29 and 
the associated component data 26 is inserted into Component Knowledge Base 
28. Component handlers 24 also perform vahdation procedures on component 
data 26 stored in knowledge base 28. Using an expressly designed rules language 
the fimctional dependencies of the component objects are encoded into an abstract 
model representing inter-component dependency rules. The encoded rules are 
inserted into knowledge base 28 creating new entries or updating the suitable 
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Referring now to Fig. 2 where a more detailed illustration of server 
system 22 software configuration is showiL Server 22 contains a component 
object and component data input module 63, a component validation module 56, a 
rules language module 58, the knowledge base 28, the component object files 80, 
a client requests module 76, a client queries and update module 70, a client 
preferences modide 72, a client preferences table 73, a knowledge base handler 
module 74, an auto-update module 82, an auto-downlbad module 84 and an 

auto-notify module 86. 

The process of creating and maiataiaing knowledge base 28 is divided 
into four distinct but logically related stages or activities: (a) component 
intelligence gathering, (b) component interdependency research, component 
object and comjponeht data input, and (c) rules validation. 

Component intelligence gatheripig 52 and component research activities 
are performed off-line by special team^. The component intelligence gathering 
team 52 handles- all the activities relating to the retrieval of the entire set of - 
available and operative Linux components and the entire set of available 
intelligence thereof All the existing types of components are collected: hardware, 
software, kernel, RPM (RedHat Package Management) packages, distributions, 
patches, utilities, editors, compilers, command iaterpreters, commercial 
applications, system tools, servers, network modules, file-systems, games, 
development tools, graphical tools, programming languages, configuration files, 
interfaces, browsers and the like. 

It will be readily perceived that each and every component could have 
a number of different versions and releases. For instance, the Vim editor used for 
text editing in UNIX-compatible systems could have two releases (Vim4 and 
Vim5) and the Vini5 version could have tiiree versions (Vim5.1, ViDi5.2 and 
yim5.3). (Components could be functionally related, for example in software 
packages comprising a pluraHly of software modules. Functionally related 
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I 

preferences module 72 is provided to respond to client systems 32 requests for 
client preferences table 73 up^es. Knowledge base handler 74 is responsive to 
the client systems 32 requests to transmit all or parts of knowledge base 28 to the 
respective client systems 32 to be used in a user-initiated client system-based 
virtual system configuration process. 

Auto-Download module 84 automatically downloads relevant 
component objects from component object fOles 80 in conjunction with the client 

s 

preferences stored in client preferences table 73. Auto-notify module 86 responds 
to specific user preferences stored in client preference table 73 in conjunction 
with Vtree 60 by transmitting notices to tiiie respective client systems 32 with 
regard to the availability of new components such as kemel patches. 

Virtual System Configurator Server system 22 preferably incorporates 
all the necessary component objects for a required computer system upgrade in a 
Linux enviromnent Server system 32 also preferably incorporates the entire set of 

r3r ... 

"the requisite component characteristics or component data for a virtual system 
configuration process in a: Linux environment. Server system 22 further develops 
and dyiiainicaUy maintains a set of rules associated with the component objects- 
that provides vital information about component object interdependencies. 

It will be appreciated by those skilled in the art that in a different 
embodiment of the present invention a different mode of operation could be used. 
The present invention is not limited to the specific mode of operation presented 

Referring now to Fig. 3 there is shown constructed and operative in 

* 

accordance with the preferred embodiment of the present invention. Knowledge 
Base 28. Knowledge Base 28 is a collection of interlinked data stmctures 
designed to provide control information for the virtual system configuration 
process. Knowledge Base 28 comprises a Vtree (Version Tree) Database 60, an 
Xor rules table 61, an Add-Remove Rules table 63, a Links Table 64, a Stamp 
table 67, a Stamp Rules table 69, and^ a Linux Update Modules (LUM) table 66. 
The fimctionalities of the tables are described next. 

-13- 
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connection between two component data records. A leaf is. a node with no 
children nodes or descendant nodes. 

Returning now to Fig. 3 where a block diagram of knowledge base 28 

5 is shown. A» component data record stored in Vtree 60 database consist of the 
following j&elds: (1) a node id or component id, (2) a component name, (3) a node 
type, (4) a father id, (5) a next brother id, (6) an install script, (7) an iininstall 
script, (8) a version nmnber, (9) a release nnmber, (10) an update module number, 
(11) an icon pointer, (12) a component name for display, (13) a component 

10 description and (14) a stamp index. The contents pfllie fields are described next. 

Node id (1) is equivalent to component id that uniquely identifies a 
component object. Component inteUigence module 52 of Fig. 2 designates all 
received components using a hierarchically organized system of numbering used 
to express the hierarchical relationships between component objects of the same ^ 

15 type or subtype. For example, component object 'Icemer could be given the , 

number 1000 and component object "kernel patch" which-is a subtype of "kerael" . , , . 

^ j: i could be giVen the number .10 10. Component name (2) is the. compoiient object . : 
name such as "compiled kernel" or "ipm". Component node type (3) indicates the 
type of the tree node such as root, leaf, node and element. Father id (4) indicates 

20 the node id of the parent node or of the node immediately above the present node 
in the tree. Next brother (5) indicates the next node in the tree with an identical 
parent node to the current node. Install script (6) is a pointer to the specific 
installation script used for the upgrading process of the component object. 
Uninstall script (7) is a pointer to the specific uninstallation script used in the 

25 upgrading of the component object Update module number (8) points to the 
appropriate entry in Linux Update Module table 66. Pointer to icon (9) is a 
pointer to the icon file associated with the component object. Name for display 
. (10) is the name of the component object to be displayed to the users. Description 
(11) is a te3ct to be displayed to the users. Stamp index (12) is a pointer to the 

30 latest stamp put on the record 

-15- 
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The Rules tables, Xor rules table 61 Add-remove rules table 63 
comprise the inter-componCTLt dependency rules. The dependency rales records 
are created utilizing the rules language. Therefore Ihe operation of the rules tables 
Avill be described hereunder in association of the rules language and the following 
drawings. 

■ 

In the preferred embodiment of the present invention each component 

9 

data, record represents an abstract component type such as *liardware'^ 
"software", "kernel", one or more abstract component subtypes such as "isa 
cards", "pci cards", 'kemel parameters", *1cemel patches" or an non-abstract 
component subtype such as "PATCH-QIC8-TAPE", "CONFIG_.IRDA", 
"EMACS3.1" and the like. The types and subtypes are organized hierarchically 

and stored into the nodes of a tree-like , data structure. The nodes are 

■ ■ ■ . * ■ ■ ' • 

interconnected by edges linking the nodes in such a manner that the node 
containing component type "kernel" is connectedUo a descendant node thereof 
containing component subtype "kernel base" that in turn connected to a 
descendant node containing component element "2.2.1", to another descendant 
node containing component element "2.2.2" and still to another descendant node 
containing component element "2.2.4". . 

Referring now to Fig. 4 which is a schematic presentation of vtree 60, 
organized as a tree-like data structure. The root node 110 is located on the top of 
tree. Root 1 10 has three descendants or "children"; a. node containing hardware 
component type 1 1 1, a node containing kernel component type 1 12 and a node 
holding RPM (Red Hat Package Management) component type 113. The tree 
node containing hardware component type 111 has tiiree children nodes or 
descendant nodes: a node holding the record ISA cards component subtype 114, a 
node holding the record of PCI (Periphraral Component Intercormect) cards 
component subtype 1 15 and a node holding the record of serial ports component 
subtype 1 16. The node holding the record of hardware component type 1 1 1 is the 

-17- 



wo 01/93020 PCT/ILOl/00209 

<COMPONENT> or <COMPQNEN'I> AND <COMPONENT SET> 
Component choice-sets are a group of integers representing component 
objects coimected with the OR logical operator. For example 3450 OR 6700 OR 

9 

1201 indicates that one of the component objects included in the component 
choice set is needed in installing a dependent component Formally, a component 
choice-set as an entity of the rule language can be defined as: 

<COMPONENT CHOICE>: 

<COMPQNENrr> or <COMPQNENT> OR <COMPONENT 

CHQICE> 

Rules-sets coiisist of a component choice-set connected with the AND 
logical operator to an another rule-set For example, (2300 OR 2306 OR 2077) 
AND (900) indicates that in order to install a specifi.c component object 
successfully, component object 900 and one of the component objects that are the 
members of the e5q)ression in the brackets are needed to bie installed as well. 
Formally, a rule-set as an entity oT the nile language can be defined as: 
-<RULESSET>:. 

<COMPONENT CHOICER or <COMPQNENT CHIOICE> AJSTD 
<RULES SET> 

Need rule-sets consist of a component set connected by the NEED 
dependency operator to a rule-set. . For example, (2300 AND 2306) NEED (900 
OR 901 OR 902) indicates that in order to be iiastalled successfully, component 
object 2300 and component object 2306 needs component object 900 or 901 or 
902 to be installed as well. Formally, a need rule-set as an entity of the rule 
language can be defined as: 

<asrEED RULE>: 

<COMPONENT SET> NEEDS <RULES SET> 

Xor rule-sets consist of an XOR logical operator and a component 
choice-set. For example, XOR (950 OR 952 OR 978) indicates that in order to 
ingtflll successfully a specific component object only one of the component 

-19- 
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objects on which "tkcvs" is depending have to be installed as well. Component 
research module 54 obtains the following dependency rule in human language: 

Tkcvs component object needs tk component object with a version 
number greater or equal to 8.0 and tkcvs needs tcl component object with a 
version number greater or equal to 8.0. 

The rule in human language is transformed by research module 54 
using rule language module 58 of Fig. 2 into the rule language expression: 

TKCVS NEEDS {(TK8.0 OR TK8.1 OR TK8.2) AND (TCL8.0 OR 
TCL8.10R-TCL8.2)} 

The expression is a need-rule coiiq)rising a distinct component object 
idaitifier, a NEED operator, and a rules-set. The rules-set comprises two 
component choice-sets connected with the AND operator. The component 
choice-set comprises of distinct component object identifiers connected by the 
OR operator. Therefore the expression is consistent with the terminology of the 
rules language. " , : . - y^" . .v 

The expression is encoded and iiiserted into add-remove rules table 63 

■ • 

in the fdiinat shown in box^-l^^^^ fTkcvs" is identified by the number 100 
therefore the field node-id is set to the same number."Tk8.0" is identified by die 
number 80 therefore the field item-id is set to the same number. "Tk8.0" is 
contained in the first bracket of the expression therefore the field cond-iudex is 
set to 1. In ihe next two records the fields node-id and cond-iudex are replicated 
and item-id is set to the value of 81 that is the identifier of component object 
"tk8. 1" and to the value 82 that is the identifier of componeut object 'tk8.2" 
respectively. In die fourth, fifth and sixth line the value of node-id is rq>licated 
wh^eas die field cond-index set to the value of 2 to denote the second bracket in 
die expression. The field item-id is respectively set to 68,69, and 70 that denote 
the component objects "tclS.O", "tcl8.1" and "tcl8.2" respectively. 

The NEED operator is assumed, as every need-rule set comprises a 
NEED operator by definitioiL In box 104 tiiere is shown the detailed underlying 
logical syntax of the add-remove rules table. 

-21- 
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The next three entries belong to the same xor-rule therefore the value of the field 
cond-index is replicated. 101 representing "glibc6.1", 128 representing "libc2,0", 
and 129 representing "libc2,l" are inserted into the field item-id of the. second, 
third and fourth entries respectively. The XOR and OR operators are assumed as 
every xor-mie set comprises a XOR and an OR operator by definition. In box 108 
there is shown the detailed underlying logical syntax of the xor-rules table. 

Consequently when a virtual installation of a speci&c component 
object will be attempted, conflict resolver module 39 of Fig. 1 will interrogate xor 
rules table 61 as for the presence of the component object in any of the xor rules 
tables. If found the other component objects associated with the same xor rule are 
checked for in the original system information table and if any of them found the 
installation of the specific component object will be aborted. 

Persons skiiled in the art will appreciate that the present invention is 
' not limited to what has been particularly shown and described hereinabove. 
Rather the scope of the present invention is defined only by the claims which 

lOllOWr : . - .. . _ . 
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of installing, uninstalling or updating component objects on said client 
systems computing platforms. 

2. The metiiod of claim 1 of researching said information fiirtlier 
comprising the steps of: 

examining said component information; 
scanning said component information; 

analyzing said component information for interconnectedness, 
interrelationships, and interdependqncy rules; 

indexing said component information according to component object 
lypeSj component object version number and inter-component dependency 
rules; 

organizing said component information into meaningful patterns of 

r 

- component data . 

- - ■ ^ • 

3, The method of claim 1 of . storing said component data foither 

comprising the steps of: . . - : . " ^ : . 

inserting specific component data according to attributes observed by 
said researching into a specific component data structure on the storage 
device of said central server system; 

inserting said dependency rules observed by said researching of 
component information into specific rules tables on said storage device of 
said central server system; 

creating iq>date modules related to specific component objects to be 
utilized in said computer object installation process and inserting said update 
modules into specific update module data structures on said storage device 
of said central server system. 



4. The method of claim 1 of encoding the functional dependencies of said 
component objects further comprising the steps of: 
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8. The melliod of claim 1 furtiier comprising requesting notifications firom 
said central server concerning new component objects or new versions of 
existing component objects by said system managers. 

9. The method of claim 1 furtibier comprising requesting automatic 
downloading of said new component objects or said new versions of 
existing component objects to said compute platform rumung said client 
system by said system managers. . 

10. A system of virtual system configurator operating in a computing 
environment on a central server system platform having a storage device, 

an I/O device, a communication device, an operating system, and virtual 

, ■ . • ... 

system configuration system comprising: 

a knowledge database to hold said component data collected firom said 
component data sources and said dependency rules produced by said 
researching of said component inforination; ^ . . ^ . ^ 

a component object database to hold said component objects coUe'cted 
fiom said component object sources; 

a user preferences table to hold user preferences regarding automatic 

downloading of said component objects, automatic notifications of said new 

. ** 

component objects or said new versions of existing component objects; 

a rules language module to handle the encoding and decoding of said 
component objects dependency rules; 

a component object and component data input module to retrieve said 
component objects and said component information; 

a component object validation module to test said abstract model of said 
component objects relationships and dependencies; 

an auto-download module to export said specific component objects to 
said client systems by, said system managers request; 

4 

-27- 
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a Stamp table to hold a historical list of said time stamps appHed to 
records of said version tree to distinguish between tiie different versions of 
records in said version tree; 

an update module table to the to an installation script file to be used 
5 during said installation, said uninstallation, and said update process of said 

component objects. 

12. The system of claim 10 of said knowledge database further comprising 
representations of abstract component types to be used as types and 

10 subtypes of said component objects. 

13. The system of claim 10 of said knowledge database further comprising 
installable component types data to be used for said installation, said 
uninstallation and said updating of said component objects. 

4. 

14. The system of claim 10 of said knowledge database further comprising 
of usefiil data fields like a pointer to said installation script type, a 
version number, a release number, a description, and a time stamp. 

20 15. The system of claim 11 of said xor rules table further comprising a rule 

index to identify the type of said xbr rule and component objects 
identifying indices to point to said component objects data in said 
version tree. 

25 

16. The system of claim 1 1 of said add-remove rules table comprising a 
component object identification index to point to said component object 
data which needs other components to operate correctiy in the same 
envh-onment 

30 
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